home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9608 / 000022_owner-urn-ietf _Sun Aug 18 23:08:08 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA11005 for urn-ietf-out; Sun, 18 Aug 1996 23:08:08 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA11000 for <urn-ietf@services.bunyip.com>; Sun, 18 Aug 1996 23:08:06 -0400
  3. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA02710  (mail destined for urn-ietf@services.bunyip.com); Sun, 18 Aug 96 23:08:04 -0400
  5. Received: from legiron.acl.lanl.gov (transitory27.lanl.gov [128.165.7.173]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id VAA04229; Sun, 18 Aug 1996 21:07:59 -0600 (MDT)
  6. Message-Id: <2.2.32.19960819031320.006aef7c@acl.lanl.gov>
  7. X-Sender: rdaniel@acl.lanl.gov
  8. X-Mailer: Windows Eudora Pro Version 2.2 (32)
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="us-ascii"
  11. Date: Sun, 18 Aug 1996 21:13:20 -0600
  12. To: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
  13. From: Ron Daniel <rdaniel@acl.lanl.gov>
  14. Subject: [URN] Re: Iterative lookup
  15. Cc: urn-ietf@bunyip.com
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: Ron Daniel <rdaniel@acl.lanl.gov>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. Thus spoke Daniel LaLiberte (at least at 12:33 AM 8/17/96 CDT)
  22.  
  23. >Thanks for the example, Ron.  That makes it abundantly clear.
  24.  
  25. Glad to do it.
  26.  
  27. > > I think it is pretty rare that we will have a namespace that
  28. > > has such a mapping to DNS.
  29. >
  30. >The path scheme requires exactly this kind of iteration and reversal
  31. >of names to get DNS names. 
  32.  
  33. I didn't say we would *never* have such a namespace.  :-)
  34.  
  35. > > [...]  I think most namespaces
  36. > > will very quickly point the user to a database that handles
  37. > > very large chunks of the namespace.
  38. >
  39. >Depends on what you mean by this.  If you mean that after the NAPTR
  40. >resolution algorithm is done, the opaque string is handled
  41. >internally to a server, then I think this is the wrong approach
  42. >because it is unscalable for really large name spaces and large
  43. >numbers of users.
  44.  
  45. That is what I mean, and I agree that it has some problems for some
  46. really large namespaces. However, some of the namespaces I have
  47. been investigating (the Intl. Std. Audiovisual Number in particular)
  48. are centrally assigned and they want them centrally resolved. Name
  49. spaces like the handle names space will probably also want to stop
  50. using NAPTRs very quickly and start talking the handle protocol.
  51.  
  52. (I'm not so sure that there are problems for large numbers of users,
  53. we can replicate the resolver because of the SRV record).
  54.  
  55. >It's OK with me that some name spaces work this way, but we should
  56. >not require it of all name spaces.  
  57.  
  58. I wouldn't dream of making everyone do it. I just think there will
  59. be a number of namespaces that are resolved that way. I also think
  60. that the more money is at stake, the more centralized the name
  61. assignment and resolution will be.
  62.  
  63.  
  64. Regards,
  65. Ron Daniel Jr.                       email: rdaniel@lanl.gov
  66. Advanced Computing Lab               voice: +1 505 665 0597
  67. MS B287                                fax: +1 505 665 4939
  68. Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
  69. Los Alamos, NM, USA  87545       tautology:"Conformity is very popular"
  70.